Skip to content

FROMLIST: misc: fastrpc: fix UAF and kernel panic during cleanup on process abort#1032

Open
Jianping-Li wants to merge 1 commit intoqualcomm-linux:tech/mm/fastrpcfrom
Jianping-Li:fearure/hamoa_race
Open

FROMLIST: misc: fastrpc: fix UAF and kernel panic during cleanup on process abort#1032
Jianping-Li wants to merge 1 commit intoqualcomm-linux:tech/mm/fastrpcfrom
Jianping-Li:fearure/hamoa_race

Conversation

@Jianping-Li
Copy link
Copy Markdown

When a userspace FastRPC client is abruptly terminated, FastRPC cleanup paths can race with device and session teardown.

This results in kernel panics in different release paths:

  • fastrpc_release() when using remote heap, originating from fastrpc_buf_free()
  • fastrpc_device_release() when using system heap, originating from fastrpc_free_map()

In addition, fastrpc_map_put() may trigger refcount use-after-free due to concurrent cleanup without proper synchronization.

The root cause is that buffer and map cleanup paths may access map and buf resources after the associated device or session has already been released.

Fix this by:

  • Introducing mutex protection for map and buf lifetime
  • Serializing buffer and map cleanup against device teardown
  • Skipping buffer and map operations when the device is already gone

These changes ensure cleanup paths are safe against unexpected process aborts and prevent use-after-free and kernel panic scenarios.

Link: https://lore.kernel.org/all/20260427105310.4056-1-jianping.li@oss.qualcomm.com/
Fixes: c68cfb7 ("misc: fastrpc: Add support for context Invoke method")
Cc: stable@kernel.org

CRs-Fixed: 4456370

…rocess abort

When a userspace FastRPC client is abruptly terminated, FastRPC
cleanup paths can race with device and session teardown.

This results in kernel panics in different release paths:
- fastrpc_release() when using remote heap, originating from
  fastrpc_buf_free()
- fastrpc_device_release() when using system heap, originating from
  fastrpc_free_map()

In addition, fastrpc_map_put() may trigger refcount use-after-free
due to concurrent cleanup without proper synchronization.

The root cause is that buffer and map cleanup paths may access map
and buf resources after the associated device or session has
already been released.

Fix this by:
- Introducing mutex protection for map and buf lifetime
- Serializing buffer and map cleanup against device teardown
- Skipping buffer and map operations when the device is already gone

These changes ensure cleanup paths are safe against unexpected
process aborts and prevent use-after-free and kernel panic scenarios.

Link: https://lore.kernel.org/all/20260427105310.4056-1-jianping.li@oss.qualcomm.com/
Fixes: c68cfb7 ("misc: fastrpc: Add support for context Invoke method")
Cc: stable@kernel.org
Signed-off-by: Jianping Li <jianping.li@oss.qualcomm.com>
@qcomlnxci qcomlnxci requested review from a team, Chennak-quic and ekanshibu and removed request for a team April 27, 2026 11:10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant